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Abstract 



Peptide Optimization is a highly complex problem and it takes very long time of compu- 
tation. This optimization process uses many software applications in a cluster running 
GNU/Linux Operating System that perform special tasks. The application to organize 
the whole optimization process had been already developed, namely SEPP (System for 
Evolutionary Pareto Optimization of Peptides/Polymers). A single peptide optimization 
takes a lot of computation time to produce a certain number of individuals. However, 
it can be accelerated by increasing the degree of parallelism as well as the number of 
nodes (processors) in the cluster. 

In this master thesis, I build a model simulating the interplay of the programs so that the 
usage of each resource (processor) can be determined and also the approximated time 
needed for the overall optimization process. There are two Evolutionary Algorithms 
that could be used in the optimization, namely Generation-based and Steady-state Evo- 
lutionary Algorithm. The results of each Evolutionary Algorithm are shown based on 
the simulations. Moreover, the results are also compared by using different parameters 
(the degree of parallelism and the number of processors) in the simulation to give an 
overview of the advantages and the disadvantages of the algorithms in terms of compu- 
tation time and resource usage. The model is built up using JavaSpaces Technology. 

Keywords: Multiobjective optimization; Evolutionary Algorithms; Parallel simulation; 
Timed Petri nets; JavaSpaces Technology. 



vii 



Contents 



viii 



1 Introduction 



1.1 Peptide 

A peptide is a polymer consisting of amino acids which are linked together. A schematic 
diagram of an amino acid is depicted in Figure [LT] A central carbon atom C a is attached 
to an amino group, NH 2 , a carboxy group COOH, a hydrogen atom, H, and a side chain, 
R. In a polypeptide chain the carboxy group of an amino acid n forms a peptide bond, 
C-N, to the amino group of amino acid n + 1, as shown in Figure [L2| [9[. 



side chain 




amino group carboxyl group 

Figure 1 . 1 : A schematic diagram of an amino acid [|9l 

Peptide units (sequence of amino acids) are building blocks of protein structures. 
There are 20 different amino acids grouped in three different categories: hydrophobic, 
charged, and polar amino acids 0. 
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peptide bond 




Figure 1.2: A polypeptide chain and a peptide bond ||9l 



1.2 Evolutionary Algorithm 

In this section, a short general description of the Evolutionary Algorithm is addressed. 
This algorithm covers an evolutionary computation and a theoretical framework of mul- 
ticriteria decision making. 

1.2.1 Multiobjective Optimization 

In multiobjective optimization, there are several possibly contradicting objectives to be 
optimized simultaneously. In general, a single optimal solution does no longer exist, 
but instead a set of possible solutions of equivalent quality which are all optimal in 
some sense. Note that to obtain the optimal solution, there is a set of optimal trade-offs 
between the contradicting objectives. 

According to |HU|26]|, a multiobjective optimization problem can be written in the 
form: 

minimize/maximize [fi(x), f2(x), • fk( x )] (1-1) 
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1.2 Evolutionary Algorithm 

subject to the m inequality constraints: 

9i {x) >0Vie{l,2,..,m} (1.2) 
and the p equality constraints: 

hi(x) = 0Vz G {1,2,. ..,p} (1.3) 

where k is the number of objective functions fa : 3? n — > 3ft. The vector of decision 
variables is x = [x\,X2, ...,x n ] T . The aim is to determine the particular set of val- 
ues [x*, x%, x*] which yield the optimum values for all the objective functions from 
among the set F of all vectors satisfying Equation |1.2| and 1.3 



1.2.2 Pareto-optimal Solutions 

In a multiobjective optimization, a solution could be best, worst, and also indifferent to 
the other solutions (neither dominating or dominated) with respect to the objective val- 
ues. Consequently, there is no unique solution to multiobjective optimization problems, 
but instead, there are a number of feasible solutions available. 

An optimal solution is the solution that is not dominated by any other solution in the 
search space. In addition, best solution means a solution which is not worst in any of 
the objectives and at least better in one objective than the other solutions in the search 
space [3J. Such an optimal solution is called Pareto-optimal, whereas the entire set of 



such optimal trade-off solutions is called Pareto-optimal set. Figure 1.3 shows possible 
solutions in the search spaceQand the Pareto-optimal solutions [OQ. More precisely, for 
a minimization problem, a vector of decision variables x* E F is called Pareto-optimal 
if -fix £ F such that fi(x) < fi(x*) Vz = {1,2,..., A;}, with at least one strict inequality: 
fj(x) < fj(x*) for at least one j. Similarly, for a maximization problem, x* £ F is 



'for the sake of simplicity, this space only represents two-dimensional objectives, but it's also analogous 
for n-dimensional objectives. 
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1 Introduction 

called Pareto-optimal if $x E F such that fi(x) > fi(x*) Vi = {1, 2, k}, with at 
least one strict inequality: fj(x) > fj(x*) for at least one j. 

1.2.3 Evolutionary Algorithm for Multiobjective Optimization 

Evolutionary algorithm is characterized by a population of existing candidates. The mu- 
tation and reproduction process enable the combination of existing solutions to generate 
new solutions. The general iterative computation process of an evolutionary algorithm 
is illustrated in Figure [L4] [l]. 

In the population, there are a number of individuals. A natural selection by fitness 
functions determines which individuals of the current population participate in the new 
population. After selection, a set of potential solutions, which are all optimal in some 
sense, is eventually produced by the algorithm. But notice that these solutions are not a 
final decision. There is a possibility to find better solutions by mutating the individuals. 
The mutation process makes replicas or copies of the individuals, in such a way that 
the characteristics (here, the sequence) of each individual are varied (mutated) based on 
stochastic processes. One of the advantages is that many types of solutions are possible 
to achieve. Some of the other advantages of using evolutionary algorithms is that they 
can be implemented in a parallel environment. 

1.3 Evolutionary Peptide Optimization 

A peptide (or protein) has a biological function. The biological function of a peptide 
depends on its three-dimensional structure characterized by its amino acid sequence. 
It necessarily follows that the amino acid sequence plays a major role to ensure the 
biological function of peptides. The things become interesting because the biological 
function of peptides is certainly possible to be optimized. In other words, optimizing 
a biological function of a peptide means finding its optimal sequence of amino acids. 
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1.3 Evolutionary Peptide Optimization 





(b) for a maximization problem 



Figure 1.3: Pareto-optimal solutions Q]| 



5 



1 Introduction 



START 



Initial 
Population 



Fitness ^_ 
Evaluation 




N 



Mutation 
and 
Reproduction 



J 



Figure 1 .4: The iterative computation process of an evolutionary algorithm HI 



Note that this optimization is not a single-objective but a multiobjective optimization, 
such as conformational stability, peptide length, degree of similarity, etc. 

There is a quasi-natural approach for the finding of optimal sequence of amino acids. 
This approach is based on Evolutionary Algorithms: Generation-based and Steady-state 
Algorithm lfT9ll23l . The algorithms change given peptide sequences towards sequences 



with increased propensity for a specific conformation. Figure 1 .5 depicts a simplified 
scheme of the Evolutionary Algorithm used for Peptide Optimization. In fact, the muta- 
tion process is able to run in parallel environment, which means that multiple mutation 
processes can run concurrently. The explanation about this concurrency in technical 
sense is addressed in Chapter [3] 

The optimization process stops after a predefined number of individuals exceeded. In 
the mutation process there are four steps of computation which are executed sequen- 
tially: compute mutation site probabilities, choose site, compute amino acid exchange 
probabilities and choose amino acid lfl9ll . 
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Start 
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Sequence 


Conformation 



Mutation Process 
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Fitness Evaluation 

Molecular Dynamics Simulation 



Analysis 
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End 



Figure 1.5: A simplified scheme of the Evolutionary Algorithm used for Peptide Opti- 
mization 
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1.3.1 Generation-based and Steady-state Evolutionary 
Algorithm 

As previously indicated, there are two types of algorithms being implemented in pep- 
tide optimization, namely Generation-based and Steady-state Evolutionary Algorithm. 
The main difference is in the occurrences of the selection process [23|. The Generation- 
based Evolutionary Algorithm performs selection after the mutation processes (includ- 
ing the fitness evaluation) have been done for all individuals. The Steady-state Evo- 
lutionary Algorithm apparently performs selections right after one individual has been 
mutated. 



A mutation process of an individual is depicted in Figure 1.6 Note that the computa- 
tion time of a mutation process ranges in a set of values and can not be exactly predicted. 
In parallel environment, a simultaneous mutation process of n individuals is possible. 
In other words, a simultaneous mutation process of n individuals consists of n mutation 



processes running concurrently. Figure 1.7 illustrates this kind of mutation process 



given individual ( x ) 



t*5 
U 

e 
&| 

e 

o 

•-D 



mutated individual ( x ' ) 

Figure 1.6: A mutation process of an individual 

The drawback of using Generation-based Evolutionary Algorithm is in the overall 
computation time. Every selection process depends on the longest mutation process 



among individuals. This kind of selection is illustrated in Figure 1.8 Notice that a 
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Figure 1.7: A simultaneous mutation process of n individuals 



mutated individual doesn't necessarily become a new individual. A new individual 
means an individual produced after a selection process. Consider that n individuals 
being computed using n processors and one individual corresponds to one processor, 
then at most n — 1 processors have idle state which supposedly could be used for other 
computations. Moreover, there will be always 2n individuals in the selection process. 
So if the simultaneous mutation and selection process is repeated so many times, hence 
the idle state of processors becomes higher. 

In contrast, the Steady-state Evolutionary Algorithm has an advantage that the idle 
state of each processor can be reduced or even omitted, because each processor does 
not need to wait until all individuals have been mutated ll23l . Nevertheless, the amount 
of the individuals in the selection process is consequently reduced, which is always only 
n + 1 individuals. 



The selection process of the Steady-state Algorithm is depicted in Figure 1.9 In the 
selection process, the best individual replaces the worst one. Hence, the new popula- 
tion always consists of n individuals. In other words, the selection process selects n 
best individuals from n + 1 individuals, which are n from the old population and 1 
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mutated individuals. In such an unlikely case that two or several mutation processes 
finish exactly at the same time, there are two options to execute the selection process: 
simultaneously or in a random sequence. The first option causes the selection processes 
have the same previous (old) population and produces several populations. The union 
of those populations may have more than n individuals which are not expected because 
of consistency. Instead, in the second option, each selection has probably different old 
population and the new population is always consistent of having n individuals. Notice 
that the execution time of the selection process, in fact, doesn't take so much time as the 
mutation process. 
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Figure 1.8: A selection of the Generation-based Algorithm 



Let's consider if the simultaneous mutation and selection process is repeated k times 
and U is a vector contains times of all mutation processes at i-th simultaneous muta- 
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tion process. It follows that the overall computation time using the Generation-based 
Algorithm is Yli=i max(ti), whereas the Steady-state Algorithm is Yli=i ^(U)- Which 
algorithm yields the better results (quality of individuals) in terms of biological function 
still has to be examined and it is not covered in this thesis. 
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1.4 Problem Description 

In this master thesis, the following problems are addressed, such as 

(a) Developing a Simulation Program 

There is a need for having such a program which can simulate the resource usage in 
parallel evolutionary peptide optimization. The program models the real situation that 
the optimization is done on a cluster using multiple resources (processors) and based on 
two evolutionary algorithms: Generation-based and Steady-state Algorithm. Moreover, 
the number of individuals (input and output), the degree of parallelism, and the number 
of resources (processors) are variable. 

(b) Approximation of Overall Computation Time 

There is a need to estimate the overall computation time for producing N new indi- 
viduals given rj individuals, where N > rj. Under this condition, the simulation runs 
using two different algorithms: Generation-based and Steady-state Algorithm. Besides, 
in the simulation some parameters are varied, such as the number of new individuals 
(N) and the number of resources. The results are then analyzed in order to evaluate 
the efficiency of the algorithms with respect to the number of new individuals and the 
overall computation time. 

(c) Efficiency of Resource Usage 

There is a need to determine the efficiency of the resource usage. Comparing both 
algorithms with various parameters is a good way to determine the efficiency. The 
efficiency of the resource usage means the ratio of the idle state to the active state of 
processors during the optimization . 
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2.1 JavaSpaces and Distributed Application 

Software applications will change very suddenly and noticeably as devices become 
ubiquitous, network-connected, and ready to communicate. As the applications changes, 
the way in which one designs and builds software will change as well: Distributed appli- 
cations involving multiple processors and devices will become the natural way to build 
systems [TTTll . 

However, designing distributed software is difficult. The main characteristics of a 
networked environment (such as heterogeneity, partial failure, and latency) and the dif- 
ficulty of gluing together multiple, independent processes into a robust, scalable appli- 
cation present the programmer with many challenges that do not occur when designing 
and building desktop applications. 

JavaSpaces technology is a simple and powerful tool that makes creating distributed 
applications easy. Processes are loosely coupled, communicating and synchronizing 
their activities using a persistent object store called an object space, rather than using 
direct communication. It can be used to store the system state and implement distributed 
algorithms. This method of coordinating distributed applications also supports heavy- 
duty parallel computations. Space-based programming relies on the Jini technology's 
leasing distributed event, and transaction features, making it suitable for building ro- 
bust, high-quality distributed systems [8]. 

1 Jini™ technology is a service oriented architecture that defines a programming model which both ex- 
ploits and extends Java™technology to enable the construction of secure, distributed systems con- 
sisting of federations of well-behaved network services and clients. For this master thesis, Jini Tech- 
nology Starter Kit v2.1 is used. 
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2 JavaSpaces Technology 

2.2 Object Space 

Object Space is a new model for developing distributed applications. All processes of 
the distributed application share an Object Space. An Object Space is a logical entity. A 
service provider expresses the service as an object: write into, read and withdraw from 
the space. Clients request the object through the required service. 

In JavaSpaces, all objects must also implement the Entry interface in which all objects 
are derived from the base class Object. Entries can be complex or a very simple that 
represent unique identities in Object Spaces. 

Object Spaces, as a computing paradigm, was put forward by David Gelernter at 
Yale University. Gelernter developed a language called Linda to support the concept of 
global object coordination ifTTl . 

Object Space can be thought of as a virtual repository, shared amongst service providers 
and clients of a network, which are abstracted as objects. Processes communicate 
among each other using these shared objects. 

An object located in a space needs to be registered with an Object Directory in the 
Object Space. Any processes can identify the object from the Object Directory, using 
properties lookup, where the property specifies the criteria for the lookup of the object. 
A process may choose to wait for an object to be placed in the Object Space, if the 
required object is not available. 

Objects located in a space are passive, whereas the methods inside the objects cannot 
be invoked while the objects are in the Object Space. Instead, the processes who needs 
to invoke methods in the requested object must retrieve it from the Object Space into its 
local memory, use the service provided by the object, update the state by invoking its 
method or public fields of the object and put it back into the Object Space [1211 . 

Object Space ensures mutual exclusion. If an object is accessed, it has to be with- 
drawn from the Object Space, and will be placed back after it has been finished. There- 
fore, no other processes can access an object while it is being used by one process. 
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As shown in Figure 2. 1 , an Object Space contains six objects with two different types 



which are rectangle and triangle. Consider that each rectangle object contains a value x 
and triangle object contains y. In Figure [2721 two processes manipulate the objects. As- 
suming that both processes are running concurrently, process one (depicted as Process 
#1) takes a triangle object and alters its value to z, while process two takes a rectangle 
object and alters its value to p. In more details, |[T7l l8ll2T|| should help the understanding 
how to get started with JavaSpaces Technology. 




Figure 2.1: An Object Space contains six objects with two different types: rectangle 
and triangle 
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Process #1 





manipulate 
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Figure 2.2: Two processes manipulate the objects concurrently 
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3.1 SEPP 

SEPP is a software developed by Manuel Prinz for our department ll23l . SEPP is an 
abbreviation of System for Evolutionary Pareto Optimization of Peptide s/Polymers and 
used to optimize peptide structures. SEPP is written in the Java Programming language. 
Moreover, several external programs also involve in SEPP, which are: 

• APBS (Advanced Poisson-Boltzmann Solver) flU, 

• Gromacs (GROningen MAchine for Chemical Simulations) [6J, being a toolbox 
for many programs, 

• PDB2PQRBEE61, 

• WhatIF ESI . 

and some other packages such as Bio Java to manipulate peptide structures E2ll . 

3.2 Master/Worker Technique 

SEPP is an software developed using Parallel Programming. It can run from start to 
finish on multiple resources, which correspond to processors. In SEPP, the processing 
is broken up into parts. The instructions from each part can run concurrently on different 
processors. The resources can exist on a single machine, or they can be processors in a 
set of computers connected via a network as shown on Figure |3Tj 
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Figure 3.1: Scheme of Master/Worker Technique 

Consider that one task takes t time units of execution time on a single processor. So 
if this task is broken up into n parts and each of which can be executed on n processors 
concurrently, the execution time then becomes - time units. The Master/Worker Tech- 
nique is used to perform this parallel computation [fT3l . The common implementation 
can be seen as follows, 
MASTER: 

• initializes tasks and splits it up according to the number of available WORKER 

• sends its split task to each WORKER 

• receives the results from each WORKER 
WORKER: 

• receives the split task from the MASTER 

• performs computation on the given task 

• returns the results to the MASTER 
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The Master/Worker Technique implements static load balancing which is usually used 
if all tasks perform the same amount of work on identical machines. An overview of 
how the Master works can be seen in the following pseudo-code: 



/* MASTER */ 




DOP = n; 




SplitTask = Task / 


n ; 


for ( i = 1 ; i <= n ; 


i++) { 


send SplitTask to 


each WORKER; 


} 




while(not all tasks 


finished) { 


wait and receive 


the results from each WORKER; 


} 





The degree of parallelism (DOP) is a metric which indicates how many processes are 
being executed simultaneously. Because one processor is responsible for one process, 
the tasks should be split with respect to the number of processors. 
And how the WORKER works can be seen also in the following pseudo-code: 



/* WORKER */ 

while (TRUE) { 

wait and receive tasks from MASTER; 
compute tasks ; 

return the result to MASTER; 

} 



3.3 Timed Petri Nets 

Petri nets were invented in 1962 by Carl Adam Petri. A Petri net is one of several math- 
ematical representations of discrete distributed systems. As a model Petri net depicts 



the structure of a distributed system in a graphical form as shown in Figure 3.2 It con 



sists of place, transition, and directed arc. Place is represented by circle and transition 
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by bar. Place may contain zero or more tokens, drawn as dot, and change during the 
execution of the net. Consider that P is an input place of a transition T if there exists a 
directed arc from P to T; P is an output place of T if there exists a directed arc from T 
to P. 




arc 



token 



P (Place) 



T (Transition) 



Figure 3.2: Petri net components 



Figure [373] shows a classical Petri net model to illustrate the states of a resource lETl . 
This Petri net models a resource which executes or processes tasks and has two states: 



idle and busy. The state shown in Figure 3.3 expresses that the resource is idle or free. 



There are four tokens in input place which represent jobs to be executed by one resource 
(processor). The token in place idle indicates that the resource is free and able to process 
a task. 



busy 




output 



idle 



Figure 3.3: One resource represented by a Petri net 



The tokens in input place will be placed into output place if all tasks had been pro- 
cessed by the resource. Transition start has two input places (input and idle), while 
transitioning has only one input place (busy) and two output places (output and idle). 
A transition is called enabled if the condition is fulfilled that each of its input places 
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contains at least one token. An enabled transition can fire which means transition T 
consumes tokens from its input places and producing tokens for its output places. 



In Figure 3.3 transition start is enabled to fire because the condition is fulfilled that 
place input and idle contain at least one token. Transition finish is not enabled because 
there are no tokens in place busy. Firing transition start means consuming two tokens, 
one from place input and the other one from place idle. Hence, it produces one token 



for place busy, as seen in Figure 3.4 



busy 




output 



idle 



Figure 3.4: Firing transition start 



In this state, shown in Figure 3.4, transitioning/? is enabled and transition start is 
disabled. Once transition finish has fired, the token in place busy is consumed and two 
tokens are then produced: one token is for place idle and the other one for output. Now 
transition start is enabled, and so on and so forth. As long as there are tasks waiting to 
be processed, those two transitions fire alternately because this Petri net model can only 



process one task at a time. The resulting state is shown in Figure 3.5 



3.3.1 Time Attributes 

Since the classical Petri net is not easily capable of handling quantitative time, a timing 
concept was added ll27ll . Each token has timestamp which represents availability for 
consumption. Timestamps indicate when tokens become available and when a transition 
becomes enabled for which each of its input places contains available tokens. Moreover, 
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busy 




output 



idle 



Figure 3.5: One task has been already executed 

timestamp is also equal to the firing time plus the firing delay of the corresponding 
transition. Consider Figure 3.6[ place input contains one token with timestamp 1, place 
idle contains a token with timestamp 5 and the firing delay is 2 time units. The transition 
start becomes enabled at time 1; the token being produced for place busy has then 
timestamp 1 + 2 + 5 = 7. 



busy 




output 



idle 



Figure 3.6: Petri net with time attributes 



A more complex example is shown in Figure 3.7 Place input contains four tokens 
with timestamps which represent tasks. These tasks need to be processed by the two 
resources. The firing delay of transition startOl is 10, the first task arrives at time 0, the 
second at time 2, the third at time 5, and the forth at time 70. The tokens in place idleOl 
and idleOl have timestamp 0. 



Figure 3.7 tells that both resources are ready to process a task at time 0. Therefore, 
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busyOl 




input 



start02 



finish02 



Figure 3.7: Two identical resources 



one of these resources will start processing a task that arrives at time 0. Let's assume that 
the first resource always takes care of the task first. Transition startOl fires at time and 
produces a token with timestamp 10 time units. Notice that this firing delay represents a 
processing time of a task which is the time required to execute the task given a specific 
resource. The intermediate state from firing transition startOl and start02 is shown in 



Figure 3.8 



At time 2 transition start02 becomes enabled. It means that the second resource starts 
to process the task arriving at time 2. Now both resources are busy until one of them 
has finished processing a task. Finally, the first resource will take care of the task with 
timestamp 5 at time 10, because from time 5 until 10 this resource was still busy, and 



the the task with timestamp 70 at time 70. Figure 3.9 shows the resulting state from 
firing transition startOl three times and startOl once. 

Each token in place output contains a vector timestamp. The first element in the vector 
expresses the time in which one of two transitions start to process the corresponding 
token; the second element apparently expresses the finishing time. As a result, Figure 
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busyOl 




idle02 



Figure 3.8: Firing transition startOl and start02 
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3.4 Timed Petri Nets and JavaSpaces Technology 



3.10 shows the overview of the resource usage over time derived from the resulting 



state in Figure 3.9 It's obvious that the resource usage is not well-distributed; P2 has 
processed less task and has more idle state comparing to PI. 
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task #2 



task#l task #3 



task #4 



10 



20 



70 



80 



time 



Figure 3.10: Resource usage over time derived from the resulting state 



3.4 Timed Petri Nets and JavaSpaces Technology 

The next question is how to implement such Petri nets with time attributes in a program. 
JavaSpaces Technology is one possibility to answer this question. As described in the 
previous chapter, JavaSpaces Technology is a simple and powerful tool that makes creat- 
ing distributed applications easy. Because Petri nets model such distributed application, 
then JavaSpaces Technology is a reasonable choice. 



In Figure 3.1 1[ an Object Space containing objects is depicted to describe the idea. 



Let's consider that in the Object Space, there are four tasks with timestamps and one 
resource (processor). This model is analogous to the model as shown in Figure [377] with 
a small difference. In the Object Space, there is only one resource available, whereas 
in the previous example there are two identical resources. This situation models a com- 
puter with one processor and four tasks. These tasks need to be processed using one 
resource. It's absolutely certain that there will be no parallelism. 

In the Object Space, task object contains an unique ID and timestamp indicating 
availability for processing. As explained, a task with timestamp t means that this task 
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task object 



processor object 



Figure 3.11: An Object Space containing four task objects and one processor object 



arrives at time t and is able to be executed at least at time t. The processor object 
contains an array which later contains vector timestamps expressing the starting and 
finishing time. As an additional constraint in the program, the processing time of each 
task is 10 time units. Figure 3.12| depicts an execution process of the first task and 
also shows that a timestamp [0, 10] is stored in the processor object. It means that the 
execution starts at time and finishes at time 10. Notice that the second task which 
actually should be executed at time 2 must wait until the first task has been executed. 
Consequently, the execution for the second task starts at time 10. This condition is also 
analogous to the third task, nevertheless the fourth task is executed at time 70. 

In the program, the time unit is implemented using a real time unit. For instance, 
to process each task, it needs 10 time units which can be implemented using real time 



units: milliseconds, seconds, etc. Eventually, Figure 3.13 depicts the final situation. It 
is shown that all tasks are already executed and only the processor object is located in 
the Object Space. The processor object contains four vector timestamps in its array. 
As a result, Figure |3 . 1 3 shows the overview of the resource usage over time derived 



from the result which is shown in Figure 3.12 It's certainly analogous for modelling a 
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[0,10] 



Figure 3.12: The execution process for the first task 



parallel computation using multiple resources. For further use, the simulation program 
is developed based on this idea. In more details, it is explained in the next chapter on 
page [33 
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Figure 3.13: The result after four execution processes finished 
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Figure 3.14: Resource usage over time derived from the result 
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4 Simulation, Results, and 
Analysis 



This chapter contains the main results on which this master thesis is focused. 



4.1 Simulation Parameters 



Figure 4.1 shows the computation steps producing a new individual from a given indi- 



vidual and the whole steps are called mutation process. The computation time for each 
step is taken from the real experiment in the computer laboratorjQ These steps are a 
simplification from the actual experiment with respect to the significance of the compu- 
tation time. It means that only computations which need to be repeated and take several 
hours are considered. Hence, the other computations are hereby neglected. 
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Mutation Preparation 

3 to 4 hours 



I 



Molecular Dynamics Simulation 

3 to 4 days 



I 



Analysis 

8 to 10 hours 



step 1 



step 2 



step 3 



Figure 4.1: Three computational steps need to produce a new individual from a given 
individual 



'the computer laboratory is located at the department I work for. This information is given by Manuel 
Prinz and Prof. Dr. Daniel Hoffmann and both are my thesis supervisors. 
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4 Simulation, Results, and Analysis 

In the simulation, those computation times are proportionally scaled in order to make 
the simulation feasible. In this case the scale is 

1 millisecond (real time) : 1000 milliseconds (simulated time) (4.1) 



The reason why the scale factor is 1000 explained on page [38 

Now consider that r\ is the number of given individuals, N is the number of produced 
individuals (new individuals), $ is the number of processors and <^ is the degree of par- 
allelism of step i. These notations are used as parameters for the simulation. Moreover, 
computation time for each step is denoted by a random variable X which is normally 
distributed^} A normal distribution in a variate X with mean /i and standard deviation o 
is a statistical distribution with the following probability function 



P(x) = ^=exp (-^f- ] r e :■)? (4.2) 
crV27T V 2a z 



Table 4.1 contains the time range for each step with the corresponding notation. Notice 



that the time range^] for each step is based on the real experiment, as shown in Figure 



4. 1 which is scaled according to the scale factor from Equation 4. 1 



Step 


Time Range (in milliseconds) 


/i (mean) 


cr (standard deviation) Notation 


1 


[10800,. ..,14400] 


12600 


3600 t sl 


2 


[259200,. ..,345600] 


302400 


86400 t s2 


3 


[28800,. ..,36000] 


32400 


7200 t s3 



Table 4.1: Time range for each computational step 



2 the simulation program had actually done a simple model based on uniformly distributed random vari- 
ables, but later changed to normal distribution because it is more realistic according to the central 
limit theorem. 

3 because negative values lead to an exception (no negative value for time), the simulation program only 
generates values that are natural numbers. 
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4.2 Generation-based vs. Steady-state Algorithm 

4.2 Generation-based vs. Steady-state Algorithm 



Before running the simulation, both algorithms are statistically compared without con- 
contains 



sidering parallelism. Let's assume that the processors are identical. Table 4.2 
the detail of parameters. Notice that all values of 5 are equal to 1, therefore one indi- 
vidual corresponds to one processor. Consider that the given individuals are computed^ 
simultaneously because r\ is less than or equal to $ (rj < $). From this it follows that 
the number of simultaneous mutation processes is equal to — . It leads to 10 simultane- 
ous mutation processes that are needed to produce 100 new individuals from 10 given 
individuals. 



V 


N 


$ 6t 5 2 6 3 


10 


100 


10 1 1 1 



Table 4.2: Parameters for statistical comparison of both algorithms 
Tgb(Vi N) and Tsriv? N) are the functions describe the overall computation time for 



Generation-based and Steady-state Algorithm respectively. The Equation 4.3 and 4.4 
show the details of both functions. 

n 

T GB ( V ,N) = ^max (xtf) + X 2 (i) + X 3 «) (4.3) 

n 

T ST (V, N) = J2^ (M^ + X 2 {i) + X 3 (i)) (4.4) 
i=\ 

where n is the number of simultaneous mutation processes with respect to rj and $ 
which is denoted by the following notion: 



^ if?7<$ 
n = { v (4.5) 

not defined if rj > $ 



"computed" means "mutated" 
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4 Simulation, Results, and Analysis 

In case that 77 is greater than $ is not investigated, even though the simulation program 
is able to do that. As an explanation for the above formulas, X\{i), X 2 {i), and X 2 {i) are 
vectors with rj elements containing random values of t si , t s2 , and t s3 at i-th simultaneous 
mutation process respectively. 

As mentioned, Generation-based Algorithm performs selection after all mutation pro- 
cesses for 77 individuals have been done. Hence Equation |4.3 is reasonable to be used, 



in order to compute the overall computation time using Generation-based Algorithm. It 
means that the maximum sums of t a \, t s2 , and t s3 at i-th to n-th simultaneous mutation 
processes are added up. In contrast, Steady-state Algorithm performs selections right 
after one individual has been mutated. It follows that i-th simultaneous mutation pro- 
cess is done at a certain time which can be computed by taking the mean value, denoted 



by fi as in Equation 4.4 of the sum of t sl , t s2 , and t s3 . Therefore n mean values of 



the sum are added up in order to compute the overall computation time of the Steady- 



state Algorithm. In Figure 4.2 the classical Petri net model shows the different type of 
selection process for Generation-based and Steady-state Algorithm. 

The overall computation time for both algorithms is done based on the parameters 



from Table 4.2 and the Equation [43] and 4.4 It is repeated 100000 times in order collect 



enough data for statistical comparison. Table 4.3 contains the summary of the results, 



whereas Figure 4.3 and 4.4 show the boxplot and histogram respectively. 



Algorithm 


Minimum 


I s * Quantile 


Median 


Mean 


3 rd Quantile 


Maximum 


ST 


3089000 


3403000 


3462000 


3463000 


3523000 


3847000 


GB 


4433000 


5190000 


5382000 


5417000 


5607000 


7921000 



Table 4.3: Summary of the results in statistical comparison 



It is now obvious that the Steady-state Algorithm is faster than the Generation-based 
Algorithm. To estimate how much faster that algorithm is, an approximation can be 
applied as described by the following speed-up function 
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4.3 Simulation Program 



given individuals 
(« individuals) 



mutated individuals 
{n individuals) 




given individuals 
(n individuals) 



mutated individual 
(J individual) 



new produced individuals 



(a) 




new produced individual 



(b) 



Figure 4.2: Classical Petri net model shows the different type of selection process for 
Generation-based and Steady-state Algorithm 



S( V ,N) 



(4.6) 



fx(T ST (v,N)) 

Thus, to produce 100 new individuals from 10 given individuals, the Steady-state Algo 
rithm is 1.56 faster than the Generation-based Algorithm. 



4.3 Simulation Program 

As explained in the previous chapter, JavaSpaces Technology is very appropriate tool to 
be used. There are three object types located in the Object Space. First, an individual 
is represented by an object instanced from the class DataEntry . java. Principally, 
this object contains an ID and the mutation index. Second, an object instanced from 
the class ProcessorEntry . java represents aprocessor. Processor object contains 
an ID and list of arrays to record timestamps. The last object is turn object instanced 
from the class TurnEntry . java to ensure an atomic collection of processors for 
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4 Simulation, Results, and Analysis 



Overall Computation Time 




STAIgorithm 



GBAIgorithm 



Figure 4.3: Boxplot of statistical comparison between Generation-based and Steady - 
state Algorithm 
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3e+064e+065e+066e+067e+06 

time in milliseconds 



Figure 4.4: Histogram of statistical comparison between Generation-based and Steady- 
state Algorithm 
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4.3 Simulation Program 

each step. It means that the execution process of step i starts after Si processors have 
been collected. 

The number of data (individual) and processor objects are dynamic. The values are 
initialized in the class InitValue . java. Initialization for time range of each step is 
also done in this class. After all classes compiled, the InsertEntry . class is run 
to place r] data objects, $ processors and one turn object into the Object Space. 

This situation models a computer cluster with $ processors and various tasks. The 
class Agent . java performs the computation for the individuals. This class is run 
using multiple threads which are implemented from interface Runnable in the class 
RunAgentGenBased . j ava and RunAgent Steady St ate . j ava. Those classes 
are run alternately depending on which algorithm is being simulated. According to the 
algorithms, maximum number of threads in the simulation of Generation-based Algo- 
rithm is always 77. Contrary to that, more than 77 threads may exist in the simulation of 
Steady-state Algorithm. 

In step i, each thread takes^] one data item (individual), the turn and Si processor 
objects from the Object Space. As mentioned above, the turn object is needed to en- 
sure the collection of processors. Notice that there is no proper scheduling algorithm 
applied to maintain the processor usage. Consequently the thread in step i randomly 
takes Si processors which are available in the Object Space^J Once the processor objects 
have been collected, the thread places back the turn object immediately into the Object 
Space and holds the data and processor objects for ^ milliseconds. Before placing 
back the objects into the Object Space, the timestamps generated by method System . 
current TimeMi 11 is ( ) are recorded in the processor objects. Moreover, the mu- 
tation index in the data object is also incremented. 



5 "take" is equal to "withdraw". 
6 according to SEPP application. 
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4.4 Analysis of Results 

Table 14.41 contains the scenario details for the simulation. Scenario eOO describes the 
real situation. For all scenarios there are 8 given individuals and 80 new produced 
individuals. Each scenario has different parameters for $ and S 2 . Parameter $ or the 
number of processors plays an important role. The efficiency of the resource usage is 
evaluated using various number of processors. As mentioned, 76 processors are based 
on the real situation. Increasing $ up to 128 is corresponding to an extension of the 
cluster. 

Moreover, parameter <5 2 or the degree of parallelism of step 2 is also another important 
issueQ It is used to examine the outcome when the degree of parallelism has been 
increased. In order to collect enough data, the simulation is repeated 100 times per 



scenario. It's now clear why those scenarios, as shown in Table [44] are chosen. But 
notice that the simulation program actually is able to handle other variations as long as 
^i)^2)^3 < because it doesn't make sense to have a degree of parallelism which is 
higher than the available processors. 



Scenario 


V 


N 


$ 


Si 


$2 


63 


eOO 


8 


80 


76 


10 


2 


2 


e02 


8 


80 


76 


10 


10 


2 


el2 


8 


80 


128 


10 


2 


2 


el4 


8 


80 


128 


10 


10 


2 



Table 4.4: Scenarios for Simulation 



For each simulation, the program generates the following log file: 



ProcID : 


1; 


start_ 


_t 


11903! 


50329418; 


stop. 


_t 


11903 


503305 


68 


data. 


.id 


2 


mutation : 


1; 


ste 


ProcID : 


1; 


start. 


_t 


11903! 


50330598; 


stop. 


_t 


11903 


503317 


93 


data. 


.id 


8 


mutation : 


1; 


ste 


ProcID : 


2; 


start. 


_t 


11903S 


50329418; 


stop. 


_t 


11903 


503305 


68 


data. 


.id 


2 


mutation : 


1; 


ste 


ProcID : 


2; 


start. 


_t 


11903S 


50330598; 


stop. 


_t 


11903 


503317 


93 


data. 


.id 


8 


mutation : 


1; 


ste 


ProcID : 


3; 


start. 


_t 


11903! 


50329418; 


stop. 


_t 


11903 


503305 


68 


data. 


.id 


2 


mutation : 


1; 


ste 


ProcID : 


3; 


start. 


_t 


11903! 


50330598; 


stop. 


_t 


11903 


503317 


93 


data. 


.id 


8 


mutation : 


1; 


ste 


ProcID : 


4; 


start. 


_t 


11903! 


50329418; 


stop. 


_t 


11903 


503305 


68 


data. 


.id 


2 


mutation : 


1; 


ste 


ProcID : 


4; 


start. 


_t 


11903! 


50330598; 


stop. 


_t 


11903 


503317 


93 


data. 


.id 


8 


mutation : 


1; 


ste 


ProcID : 


5; 


start. 


_t 


11903! 


50517645; 


stop. 


_t 


11903 


505188 


51 


data. 


.id 


5 


mutation : 


2; 


ste 


ProcID : 


5; 


start. 


_t 


11903! 


50704474; 


stop. 


_t 


11903 


50705754 


data. 


.id 


2 


mutation : 


3; 


ste 



7 As a matter of fact, parameters Si and £3 are also important. But for the sake of simplicity, the simula- 
tion only considers the most dominating computation time which is 62- 
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Notice that this log file is truncated. In fact, each log file consists of thousands of 
lines. By taking the lowest timestamp and subtracting all timestamps with it and some 
modifications, the above log file can be converted as follows: 



ProcID : 


1 


start. 


_t 




0; 


stop. 


t 


1150; 


used : 


1150ms; 


data. 


.id 


2; 


mutation : 


1; 


step : 


1 


ProcID : 


1 


start. 


_t 


Hi 


SO; 


stop. 


t 


2375; 


used : 


1195ms ; 


data. 


.id 


8; 


mutation : 


1; 


step : 


1 


ProcID : 


2 


start. 


_t 




0; 


stop. 


_t 


1150; 


used : 


1150ms; 


data. 


.id 


2; 


mutation : 


1; 


step : 


1 


ProcID : 


2 


start. 


_t 


111 


SO; 


stop. 


_t 


2375; 


used : 


1195ms; 


data. 


.id 


8; 


mutation : 


1; 


step : 


1 


ProcID : 


3 


start. 


_t 




0; 


stop. 


t 


1150; 


used : 


1150ms ; 


data. 


.id 


2; 


mutation : 


1; 


step : 


1 


ProcID : 


3 


start. 


_t 


Hi 


SO; 


stop. 


t 


2375; 


used : 


1195ms ; 


data. 


.id 


8; 


mutation : 


1; 


step : 


1 


ProcID : 


4 


start. 


_t 




0; 


stop. 


t 


1150; 


used : 


1150ms; 


data. 


.id 


2; 


mutation : 


1; 


step : 


1 


ProcID : 


4 


start. 


_t 


Hi 


SO; 


stop. 


t 


2375; 


used : 


1195ms ; 


data. 


.id 


8; 


mutation : 


1; 


step : 


1 


ProcID : 


5 


start. 


_t 


188277; 


stop. 


t 


189433; 


used : 


115 6ms; 


data. 


.id 


5; 


mutation : 


2; 


step : 


1 


ProcID : 


5 


start. 


_t 


375056; 


stop. 


t 


376336; 


used : 


12 8 0ms; 


data. 


.id 


2; 


mutation : 


3; 


step : 


1 



As a result, Figure 4.5 shows the overview of the resource usage over time derived from 
the converted log file. It's now obvious that the resource usage^Jcan be determined. In 
addition, the overall computation time for all scenarios can be approximated by sub- 
tracting the highest timestamp with the lowest one. Consider that the highest timestamp 
is Oh and the lowest is 9i, the following function, denoted by r(r],N), describes the 
approximation of the overall computation time. 



P 4 



o 

Co 

g 



Pi 



individual #2 
mutation 1; step 1 


individual #8 

mutation 1; step 1 


individual #2 

mutation 1; step 1 


individual #8 
mutation 1; step 1 


individual #2 

mutation 1; step 1 


individual #8 

mutation 1; step 1 


individual #2 

mutation 1; step 1 


individual #8 

mutation 1; step 1 



individual #5 
mutation 2; step 1 



individual #2 
mutation 3; step 1 



1150 



2375 



188277 



189433 



375056 



376336 time (ms) 



Figure 4.5: Resource usage over time derived from the log file 



8 usage of each processor. 
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4 Simulation, Results, and Analysis 



T(T], N) Bi (9 h - 6l) - ^overhead 



(4.7) 



It necessarily follows that the speed-up function also becomes different, described as 
follows 



S S (V,N) 



(4.8) 



As an explanation, tgb(Vj N) and f 5^(77, N) are vectors of the overall computation time 
with 100 elements and contain the results of the simulations based on Generation-based 



and Steady-state Algorithm respectively. Table 4.5 contains the summary of the results 



Scenario 


Minimum 


I s * Quantile 


Median 


Mean 


3 rd Quantile 


Maximum 


eOO S T 


1670000 


1839000 


1891000 


1893000 


1952000 


2121000 


e00 GB 


2102000 


2255000 


2314000 


2314000 


2364000 


2522000 


e02 ST 


488000 


520700 


531700 


533100 


544700 


579100 


e02 GB 


635400 


675600 


695000 


694800 


714200 


770100 


el2sr 


1687000 


1808000 


1872000 


1869000 


1932000 


2051000 


el2 GB 


2101000 


2240000 


2287000 


2298000 


2351000 


2468000 


el4 ST 


490800 


510300 


519800 


521700 


528400 


583900 


el4 GB 


576000 


603300 


609700 


614600 


625400 


691800 



Table 4.5: Summary of the results for all simulations 



By taking into account that there exists computational overhead and the timestamp is 
in milliseconds which are error-prone during the execution, the scale factor is reduced to 
compensate this problem. As seen in Equation |4.1[ the scale factor is 1000 even though 
the higher scale factor is also possible. Consequently the ratio of ^j^ftf becomes very 
small and therefore ^overhead is neglected. Furthermore, the results, as contained in Ta- 



ble |4.5[ considerably make sense because there also exists computational overhead in 
the real computation. To be more clear, the results which are in milliseconds are con- 



verted into days. Table 4.6 contains the conversion and the approximated speed-up. In 



addition, Figure 4.6 4.7 4.8 and 4.9 show the boxplots of all scenarios, whereas the 



histograms of the overall computation time are given in Appendix [Bj 
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4.4 Analysis of Results 



As an interesting thing, as seen in Table 4.5 the number of processor ($) doesn't 
matter to the overall computation time based on the results of scenario eOO and el 2. 
But notice that this is only for 77 much smaller than $. In contrast, the degree of paral- 
lelism (62) plays an important role to accelerate the overall computation time. It's also 
interesting to see the results of scenario e02 and el4 whose <5 2 is five times bigger than 
the previous scenarios. For the Generation-based Algorithm, increasing $ produces 
the slightly different results. Nevertheless, the Steady-state Algorithm yields the better 
results at the overall computation time. 

Scenario 77 N $ 6[ 5 2 5 3 fi(T ST (v,N)) fi(f GB (r), N)) S s (r],N) 

(in days) (in days) 

eOO 8 80 76 10 2 2~ 21.91 26.78 1.22 

e02 8 80 76 10 10 2 6.17 8.04 1.30 

el2 8 80 128 10 2 2 21.63 26.60 1.23 

el4 8 80 128 10 10 2 6.04 7.11 1.18 

Table 4.6: Time of approximated overall computation time and speed-up 
As a further analysis, the idle and active state of processors are also investigated. The 



processor states are inherently shown in more wide view as depicted in Figure 4.6 4.7 



4.8 and 4.9 It is clearly seen that the Steady-state Algorithm is more efficient than the 



Generation-based Algorithm with respect to the resource usage. Table 4.7 contains the 
processor states and the ratio of the idle to active state for all scenarios. 



Scenario 


»(r(r),N)) 


y> (^active) 


M^idle) 


M(fidlc) 

/^(^activc ) 


e00 ST 


1893000 


366900 


1298000 


3.54 


e00 GB 


2314000 


364400 


1790000 


4.91 


e02sr 


533100 


365300 


123700 


0.34 


e02 GB 


694800 


365900 


301000 


0.82 


el 2 ST 


1744592 


218400 


1526192 


6.99 


el2 GB 


1857025 


218300 


1638725 


7.51 


el4 S T 


521700 


217400 


251500 


1.16 


e!4 GB 


614600 


217200 


361000 


1.66 



Table 4.7: Resource usage (active and idle state) for all scenarios 
As an explanation, f act ivc and t^ie are vectors with $ elements containing the active 
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Active State 



8 




ST_Algorithm GB_Algorithm 



Overall Computation Time 




ST_Algorithm GB_Algorithm 



Figure 4.6: Boxplots of scenario eOO 
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Figure 4.7: Boxplots of scenario e02 
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Active State 




ST_Algorithm GB_Algorithm 



Overall Computation Time 




ST_Algorithm GB_Algorithm 



Figure 4.8: Boxplots of scenario e!2 
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4.4 Analysis of Results 





Overall Computation Time 




Figure 4.9: Boxplots of scenario e!4 
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and idle state of processors respectively. As a result of scenario eOO, it is obviously 
shown that the idle state is much higher than the active state. In contrast, the active 
state is higher than the idle state for scenario e02. It explains that the the resource usage 
becomes more efficient by increasing 82 . As another fact, the efficiency of the resource 
usage decreases by increasing the number of processors from 76 to 128, as shown in 
scenario el 2 and el 4. 
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5 Conclusion and Future Work 



5.1 Conclusion 

In this chapter, some achievements from three points of view are described as follows 

Degree of Parallelism 

The degree of parallelism plays an important role in the computation. It accelerates 
the computation time and the resource usage becomes more efficient. Hence it con- 
cludes that a particular work to increase the degree of parallelism should be done. 

Number of Processors 

Increasing the number of processors is considerably not a good solution. Many pro- 
cessors are not useful to speed up the computation time and it is expensive if the ratio 
of the idle to active state of each processor is high. It's considerably more useful to use 
few processors but efficient which means that the idle state of each processor is much 
smaller than the active one. Based on the present results, the available resources are 
theoretically possible to produce more new individuals. 

Efficiency of the Algorithms 

As a fact of the results, the Steady-state Algorithm is better than the Generation- 
based Algorithm with respect to the computation time and resource usage. So it is 
highly recommended to use the Steady-state Algorithm for parallel evolutionary peptide 
optimization. 
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5 Conclusion and Future Work 

5.2 Future Work 



There are possibilities to work further based on the results, such as 
Prediction about Minimum Resources 

In some facts, it's explained that increasing the number of processors doesn't matter 
to speed up the computation time. Therefore, it is interesting to know the minimum 
resources to perform the computation producing the same results. This prediction is 
useful to make the resources are efficiently used in the real situation. 
Scheduling Algorithm 

The other possibility is implementing a scheduling algorithm. It is highly recom- 
mended to be implemented in order to maintain the resource usage and useful to in- 
crease the efficiency of the resource usage. If the algorithm yields the better results in 
the simulation than present, it is also appropriate to be implemented in the real situation. 
In addition, it also helps to solve the problem if the degree of parallelism is not feasible 
to be increased. 
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Source Code 



These are the complete source codes of my program: 

Listing A.l: Agent.java 

/* * 

* Agent . Java — processing the data 

* @author: Andias Wira—Alam <andias . alam@ stud . uni— due . de> 
*/ 

import net . j i n i . space . JavaSpace ; 
import net. jini. core. lease. Lease; 

public class Agent implements Runnable { 

private JavaSpace space ; 

public Agent() { 

System . out . println ("Searching_for„JavaSpace . . . "); 
Lookup finder = new Lookup ( JavaSpace . class ) ; 
JavaSpace space = (JavaSpace) f in der . g et S er v ice ( ) ; 
System . out . println ( "A„ JavaSpace „ has „been„found !"); 

} 

public Agent ( JavaSpace space) { 
this . space = space ; 

} 

public void run() { 
try { 

System. out. println("Starting„Agent!"); 

ProcessorEntry ptemplate = new Proc e s s orEntry ( ) ; // Processor object template 
ProcessorEntry [] presult = null; 

DataEntry dtemplate = new DataEntryO; // Data object template 

DataEntry dresult = new DataEntryO; 

TurnEntry turn = new TurnEntryO; 

InitValue init = new InitValueQ; 

GenRandomTime gen = new GenRandomTime ( ) ; 

long start = 0, stop = 0; 

int time_step = 0; 

boolean isDataValid = false ; 

System . out . println ("Taking„processor „and„data „ obj ec t s „from„ the „ space ...„"); 

// take 1 VALID Data from the space. 
while (! isDataValid ) { 

dresult = (DataEntry) space . take ( dtemplate , null, Long . MAX_VALUE ) ; 
if ( dresult . mutationlndex . intValue () < i n i t . numOfMutation ) { 
dresult . incrementlndex () ; // increment the Mutation Index. 
isDataValid = true ; 

} 

else 
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space . write ( dresult , null, Lease .FOREVER) ; 

} 

for(int i = l; i <= i n i t . numOfStep ; i++) { // repeat acc . to the # of steps. 
presult = new ProcessorEntry [ gen . getPar ( i ) ] ; 

space . take ( turn , null, Long .MAXJVALUE) ; // wait until its turn. 
for(int j=0; j < gen . getPar ( i ) ; j ++) { // repeat acc. to the # of parallelism. 
presult [j ] = (ProcessorEntry) space . take ( ptemplate , null, Long .MAXJVALUE) ; 

} 

space . write ( turn , null, Lease .FOREVER) ; // freeing turn. 
start = System . currentTimeMillis () ; 
do { // avoid negative time step 

time_step = gen . getTime ( i ) ; 
} while ( time .step <()); 

Thread . sleep(time_step/gen. getPar(i )); 
stop = System . currentTimeMi Hi s () ; 

// assign values into array in the processor object. 

for(int k=0; k < gen . getPar ( i ) ; k++) { // repeat acc. to the # of parallelism 

presult[k].addRecord (start, stop, dresult. data_id.intValue(), 
dresult . mutationlndex . intValue () , i ); 

System . out . println ("ProcID : „" + pre s u 1 1 [k ] . proc _id + " ; „ s t a r t _ t : „" +start + 
";„stop_t:„" +stop+ ";„data_id:„" + dresult. data_id. intValue () + 
" ; ^mutation : „" + dre s u It . mutationlndex . intValue ()+ ";„step:„" +i); 

// write hack the processor object. 

space . write ( presult [k] , null, Lease .FOREVER) ; 

} 

presult = null ; 

} 

// write back the Data object into the space. 
space . write ( dresult , null, Lease .FOREVER) ; 
System, out. println ("Done !" ); 

} catch ( Exception e) { 
e. printStackTrace (); 

} 

} 

public static void main(String argv[]) { 
(new Thread(new Agent ())). start () ; 

} 

} 



Listing A. 2: CleanSpace.java 

/* * 

* CleanSpace . java — cleaning objects from the space 

* @author: Andias Wira—Alam <andias . alam@ stud . uni— due . de> 
*/ 

import net . j i n i . space . JavaSpace ; 
import net.jini .core. lease. Lease; 

public class CleanSpace implements Runnable { 
public void run ( ) { 
try { 

System . out . println ("Searching„for„JavaSpace . . . " ); 
Lookup finder = new Lookup ( JavaSpace . class ) ; 
JavaSpace space = (JavaSpace) f in der . g et S er v ice ( ) ; 

System .out.println( "A„ JavaSpace „has „ been „ found !\nCleaning„objects „from „ t he „ space ... „" ) ; 
int i = 0; 

while ( space . readlfExi st s ( null , null, Long .MAXJVALUE) != null ) { 
space . take ( null , null, Long .MAXJVALUE) ; 

i ++; 

} 

If (i — i) { 

System. out. print(i+ "„object„"); 

} 
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else if(i==0) { 

System. out. print("No„objects„"); 

} 

else { 

System. out. print(i+ " „ o bj ec t s „" ) ; 

} 

System .out.println (" had „ been ^removed !" ) ; 

System . out . println ("Done ! " ) ; 
} catch ( Exception e) { 
e. printStackTrace (); 

} 

} 

public static void main( String argv[]) { 
(new Thread(new CleanSpace ( ) ) ) . s t ar t ( ) ; 

} 

} 



Listing A. 3: DataEntry.java 

/* * 

* DataEntry.java — representing individu 

* @author: Andias Wira—Alam <andias . alam@ stud . uni— due . de> 
*/ 

import net . j i n i . core . entry .* ; 

public class DataEntry implements Entry { 
public Integer data.id = null; 

public Integer mutationlndex = null ; 

public DataEntry () {} 

public DataEntry ( int id) { 
data_id = new Integer(id); 
mutationlndex = new Integer (0); 

} 

public String getDatalDQ { 
return "DataID:„" + data_id ; 

} 

public void incrementlndex ( ) { 

mutationlndex = new Integer ( mutationlndex . intValue () + 1); 

} 

} 



Listing A. 4: GenRandomTime.java 

/* * 

* GenRandomTime . java — generating random time for computation 

* ©author: Andias Wira—Alam <andias . alam@ stud . uni— due . de> 
*/ 

import java. u t i 1 . * ; 

public class GenRandomTime { 

private int low; 

private int up; 

private int par; // degree of parallelism 
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private int mean; 

private int sdev ; // standard deviation 
private InitValue init = new InitValue (); 

public GenRandomTime ( ) { // no—arg constructor assigns default values 
low = 100; 
up = 100; 
par = 1; 

} 

public int random () { // normal distribution random generator 
float vl , v2 , s , y ; 
Random gen = new Random (); 
mean = (up + low) / 2; 
sdev = (up — low ) ; 
do { 

vl = 2 * (float) gen . nextDouble ( ) — 1 ; // between — 1.0 and 1.0 
v2 = 2 * (float) gen . nextDouble ( ) — 1; // between —1.0 and 1.0 
s = vl * vl + v2 * v2 ; 
} while (s >= 1); 

float multiplier = (float) Math . s q r t ( — 2 * Math . log ( s )/ s ) ; 

y = vl * multiplier ; 

return (int) (mean + y * sdev); 



public int getTime(int step) { 

if(step==l) { // Mutation Preparation — 3 until 4 hours 
low = i n i t . step 1 .low ; 
up = init. step 1 _up ; 

} 

if(step==2) { // MD Simulation — 3 until 4 days (not more than two processors) 
low = init . step2_low ; 
up = init . step2_up ; 

} 

if(step==3) { // Analysis — 8 until 10 hours 
low = i n i t . step3 _lo w ; 
up = init . step3_up ; 

} 

return random (); 



public int getPar(int step) { 
if(step==l) { 

par = i n i t . s tep 1 _par ; 

} 

if(step==2) { 

par = init . step2_par ; 

} 

if(step==3) { 

par = init . step3_par ; 

} 

return par ; 



} 



Listing A. 5: Init Value, java 

/* * 

* InitValue . java — initializing all values 

* @author: Andias Wira—Alam <andias . alam@ stud . uni— due . de> 
*/ 

public class InitValue { 
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public int numOfData = 8; 

public int numOfProcessor = 76; 

public int numOfStep = 3; 

public int numOf'Mutation = 10; 

/** Values for GenRandomTime */ 

// Time for Stepl: Mutation Preparation (3 until 4 hours) 

public int stepl_low = 10800; 

public int stepl.up = 14400; 

public int stepl_par = 10; // degree of parallelism 

// Time for Step2 : MD Simulation — 3 until 4 days 
public int step2_low = 259200; 
public int step2_up = 345600; 

public int step2_par = 10; // degree of parallelism 

// Time for Step3 : Analysis — 8 until 10 hours 
public int step3_low = 28800; 
public int step3_up = 36000; 

public int step3_par = 2; // degree of parallelism 

/** my no—arg constructor */ 
public InitValue () {} 

} 



Listing A. 6: InsertEntry.java 

/* * 

* InsertEntry . Java — inserting all entries into the space 

* @author: Andias Wira—Alam <andias . alam@ stud . uni— due . de> 
*/ 

import net . j i n i . space . JavaSpace ; 
import java.rmi.*; 
import net . j i n i . core . event .* ; 
import net . jini . core . transaction .* ; 
import net . j ini . core . lease .* ; 

public class InsertEntry implements Runnable { 
public void run () { 
try { 

ProcessorEntry processor = new Proc e s s orEn try ( ) ; 
DataEntry data = new DataEntryQ; 
InitValue init = new InitValue (); 
TurnEntry turn = new TurnEntryO; 

System . out . println ("Searching„for„JavaSpace . . . " ); 
Lookup finder = new Lookup ( JavaSpace . cl ass ) ; 
JavaSpace space = (JavaSpace) finder . getService () ; 
System .out.println( "A„ JavaSpace „ has „ been _ found ! " ) ; 

System, out. println("Writing„objects„into„the„space..."); 

if ( space . readlf'Exi st s ( processor , null, Long .MAX_VALUE) == null) 
for(int i = l; i <=i n i t . numOfProcessor ; i ++) { 

space, write (new ProcessorEntry (i .System. currentTimeMillis ()) , null , 
Lease .FOREVER); 

} 

else 

System. out. println("Object„\"processor\"„has„already„existed!"); 
if ( space . readlfExi st s ( data , null, Long .MAXJVALUE) == null) 
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for(int i = l; i <=i n i t . numOfData ; i++) { 

space . write (new DataEntry ( i ) , null, Lease .FOREVER) ; 

} 

else 

System, out. println("Object„\"data\"„has„already„existed!"); 

if ( space . readlfExi st s ( turn , null, Long .MAXJVALUE) == null) 

space . write ( turn , null, Lease .FOREVER) ; 
else 

System, out. println("Object„\"turn\"„has„already„existed!"); 

} catch ( Exception e) { 
e. printStackTrace (); 

} 

} 

public static void main(String argv[]) { 
try { 

Thread cleanspace = new Thread(new CleanSpace ( ) ) ; 
Thread insertentry = new Thread(new InsertEntry ( ) ) ; 

cleanspace . start () ; // start the first Thread 

cleanspace . j oin () ; // pause the execution of the next Thread until 

// the first finished 
insertentry . start () ; // start the second Thread 

} catch ( Exception e) { 
e. printStackTrace (); 

} 

} 

} 



Listing A.7: Lookup.java 

/* * 

* Lookup . Java — external code by Dan Creswell 
*/ 



import 


java 


. io . 


IOException ; 


import 


java 


. rmi 


. RemoteException ; 


import 
import 


net . 
net . 


jini 
jini 


.core, lookup. ServiceRegistrar; 
. core . lookup . ServiceTemplate ; 


import 
import 
import 


net . 
net . 
net . 


jini 
jini 
jini 


. discovery . LookupDiscovery ; 
. discovery . DiscoveryListener ; 
. discovery . DiscoveryEvent ; 


/* * 









A class which supports a simple JINI multicast lookup. It doesn't register 
with any S e rvic e Re gi strar s it simply interrogates each one that's 
discovered for a Serviceltem associated with the passed interface class, 
i.e. The service needs to already have registered because we won't notice 
new arrivals . [ServiceRegistrar is the interface implemented by JINI 
lookup services ]. 

@todo Be more dynamic in our lookups — see above 

@author Dan Creswell (dan@dancres.org) 
©version 1.00, 7/9/2003 

*/ 

class Lookup implements DiscoveryListener { 
private ServiceTemplate theTemplate ; 
private LookupDiscovery theDiscoverer ; 

private Object theProxy ; 
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/* * 

@param aS erv ic e Int erf ac e the class of the type of service you are 
looking for. Class is usually an interface class. 

*/ 

Lookup(Class aS er v i c elnt erf ac e ) { 

Class [] myServiceTypes = new Class [] { a S er v i c e In t erf ac e } ; 
theTemplate = new ServiceTemplate ( null , myServiceTypes, null); 



/* * 

Having created a Lookup (which means it now knows what type of service 
you require), invoke this method to attempt to locate a service 
of that type. The result should be cast to the interface of the 
service you originally specified to the constructor . 

©return proxy for the service type you requested — could be an rmi 
stub or an intelligent proxy. 

*/ 

Object getService() { 

synchronized ( this ) { 

if ( theDiscoverer == null) { 

try { 

theDiscoverer = 

new LookupDiscovery(LookupDiscovery . ALL.GROUPS ) ; 
theDiscoverer. addDiscoveryListener( this); 
} catch (IOException anIOE) { 

System, err . println ("Failed„to„init„lookup"); 
anIOE . printStackTrace( System . err ) ; 

} 

} 

} 

return waitForProxy ( ) ; 

} 

/* * 

Location of a service causes the creation of some threads. Call this 
method to shut those threads down either before exiting or after a 
proxy has been returned from getService ( ) . 

*/ 

void terminate () { 

synchronized ( this ) { 

if (theDiscoverer != null) 

theDiscoverer. terminate (); 

} 

} 

/* * 

Caller of getService ends up here, blocked until we find a proxy, 
©return the newly downloaded proxy 

*/ 

private Object waitForProxy () { 
synchronized ( this ) { 

while (theProxy == null) { 

try { 

wait () ; 

} catch ( InterruptedException anIE) { 
} 

} 

return theProxy ; 

} 

} 

/* * 
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Invoked to inform a blocked client waiting in waitForProxy that 
one is now available. 

@param aProxy the newly downloaded proxy 

*/ 

private void signalGotProxy ( Obj ect aProxy) { 
synchronized ( this ) { 

if (theProxy == null) { 
theProxy = aProxy ; 
notify ( ) ; 

} 

} 

} 

/* * 

Everytime a new S e rvic eRe gi strar is found, we will be called back on 
this interface with a reference to it. We then ask it for a service 
instance of the type specified in our constructor . 

*/ 

public void discovered ( DiscoveryEvent anEvent) { 
synchronized ( this ) { 

if (theProxy != null) 
return ; 

} 

ServiceRegistrar [] myRegs = anEvent . g e tR e g i s trar s () ; 

for (int i = 0; i < myRegs . length ; i++) { 
ServiceRegistrar myReg = myRegs[i]; 

Object myProxy = null ; 

try { 

myProxy = myReg . lookup ( theTemplate ) ; 

if (myProxy != null) { 

signalGotProxy ( myProxy ) ; 
break ; 

} 

} catch ( RemoteException anRE) { 

System . err . print In (" ServiceRegistrar „ barfed" ) ; 
anRE . printStackTrace (System . err ); 

} 

} 

} 

/* * 

When a ServiceRegistrar "disappears" due to network partition etc. 
we will be advised via a call to this method — as we only care about 
new S ervic eRe gist rar s , we do nothing here. 

*/ 

public void discarded ( DiscoveryEvent anEvent) { 
} 

} 



Listing A. 8: ProcessorEntry.java 

/* * 

* ProcessorEntry . Java — representing processor 

* @author: Andias Wira—Alam <andias . alam@ stud . uni— due . de> 
*/ 

import net . j i n i . core . entry .* ; 
import java . util . ArrayList ; 

public class ProcessorEntry implements Entry { 
public Long start_time = null; 
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public ArrayList<Long> recordlist = null; 



public ArrayList<ArrayList<Long» record = null ; 
public Integer proc.id = null; 
public ProcessorEntry () {} 

public ProcessorEntry ( int id, long time) { 
start_time = new Long(time); 
proc_id = new Integer(id); 

record = new Array List <ArrayList <Long > >(); 

} 

public void init(int id, long time) { 
start.time = new Long(time); 
p r o c _ i d = new Integer(id); 

record = new Array List <ArrayList <Long > >(); 

} 

public void addRecord ( long start , long stop, long data.id, long mutation, long step) { 
this . recordlist = new Array Li st <Long >() ; 
this . recordlist .add( new Long ( start ) ) ; 
this . recordlist .add( new Long ( s t o p ) ) ; 
this . recordlist . add (new Long (data.id ) ) ; 
this . recordlist . add (new Long (mutation )); 
this . recordlist .add( new Long ( s t e p ) ) ; 
this. record. add( recordlist ); 

} 

public long get_record ( int i, int j) { 

return record . get ( i ). get (j ) ; 

} 

public int get_size() { 
return record . size () ; 

} 

public void addRecord ( long start , long stop) { 
recordlist = new Array List <Long >() ; 
recordlist . add(new Long ( s t a r t ) ) ; 
recordlist . add(new Long(stop)); 
record .add(recordlist ); 

} 

} 



Listing A. 9: RunAgentGenBased.java 

/* * 

* RunAgentGenBased . java — Agent running Generation— based Algorithm 

* ©author: Andias Wira—Alam <andias . alam@ stud . uni— due . de> 
*/ 

import net . j i n i . space . JavaSpace ; 
import java.rmi.*; 
import net . j i n i . core . event .* ; 
import net.jini .core, transaction .*; 
import net . j ini . core . lease .* ; 

public class RunAgentGenBased implements Runnable { 

private JavaSpace space ; 

public RunAgentGenBased ( ) { 

System . out . prin tin (" Searching „f or „ JavaSpace ...") ; 
Lookup finder = new Lookup ( JavaSpace . class ) ; 
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JavaSpace space = (JavaSpace) f in der . g e t S er vice ( ) ; 
System.out.println( "A„ JavaSpace - has „ been „ found ! " ) ; 

} 

public RunAgentGenBased ( JavaSpace space) { 
this . space = space ; 

} 

public void run ( ) { 
try { 

InitValue init = new InitValue (); 

Thread [] agent = new Thread [ i n i t . numOfData ] ; 

// create Threads acc . to the # of Data 
for(int i=0; i<i n i t . numOfData ; i++) { 

agent [i] = new Thread(new Agent ( space )) ; 

} 

// start Threads acc. to the # of Data 
for(int j=0; j <i n i t . numOfData ; j ++) { 
agent [ j ] . start () ; 

} 

// implement Gen— based Algorithm 
for(int k = 0; k<i n i t . numOfData ; k++) { 
agent [k] . join () ; 

} 

} catch ( Exception e) { 
e. printStackTrace (); 

} 

} 

public static void main(String argv[]) { 

(new Thread(new RunAgentGenBased ())). s t art () ; 

} 

} 



Listing A. 10: RunAgent.java 

/* * 

* RunAgent . Java — daemon for Agent 

* @author: Andias Wira—Alam <andias . alam@ stud . uni— due . de> 
*/ 

import net . j i n i . space . JavaSpace ; 
import java.rmi.*; 
import net . j i n i . core . event .* ; 
import net .jini . core . transaction .*; 
import net . j i n i . core . le as e . * ; 

public class RunAgent { 

public static void stop() { 

System, out. println(" Usage: „RunAgent„{ gen— based | steady — state}"); 
System . exit ( 1 ) ; 

} 

public static void main(String argv[]) { 
try { 

InitValue init = new InitValue (); 
Lookup finder = null ; 
JavaSpace space = null ; 
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Thread [] agent = null; 

if ( argv . length==0 || argv . length >=2) { 
stop () ; 

} 

if ( argv [0] . equals ("gen— based") || argv [0] . equals (" steady — state " )) { 
System. out. println("Searching„for„JavaSpace..."); 
finder = new Lookup ( JavaSpace . class ) ; 
space = (JavaSpace) f inder . getS er vice ( ) ; 
Sys tern. out. print In ( "A„ JavaSpace „ has „been -found!"); 

} 

if(argv [0]. equals( "gen— based " ) ) { 

agent = new Thread [ init . numOfMutation ] ; 

for(int i=0; i < i n i t . numOfMutation ; i++) { // Threads for Gen—based Algorithm 
agent [ i ] = new Thread(new RunAgentGenBased ( space )) ; 

} 

for(int j =0; j<init . numOfMutation ; j ++) { // implement Gen— based Algorithm 
agent [j ] . start ( ) ; 
agent [j ] . join () ; 

} 

} 

else if ( argv [0] . equals (" steady — state " )) { 
agent = new Thread [ init . numOfData ] ; 

for(int i=0; i<init . numOfData ; i++) { // Threads for Steady — state Algorithm 
agent [ i ] = new Thread(new RunAgentSteady State ( space )) ; 

} 

for(int j =0; j<init . numOfData ; j ++) { // implement Steady — state Algorithm 
agent [ j ] . start () ; 

} 

} 

else 

stop () ; 

} catch ( Exception e) { 
e. printStackTrace (); 

} 

} 

} 



Listing A. 11: RunAgentSteadyState.java 

/* * 

* RunAgentSteady State . Java — Agent running Steady State Algorithm 

* @author: Andias Wira—Alam <andias . alam@ stud . uni— due . de> 
*/ 

import net . j i n i . space . JavaSpace ; 
import java.rmi.*; 
import net . j i n i . core . event .* ; 
import net.jini .core, transaction .*; 
import net . j i n i . core . 1 e as e . * ; 

public class RunAgentSteady State implements Runnable { 
private JavaSpace space ; 

public RunAgentSteady State ( JavaSpace space) { 
this . space = space ; 

} 

public RunAgentSteady State () { 

System . out . prin tin (" Searching „f or „ JavaSpace ...") ; 
Lookup finder = new Lookup ( JavaSpace . class ) ; 
JavaSpace space = (JavaSpace) f in der . g et S er v ice ( ) ; 
System, out. prin 1 1 n ( "A„ JavaSpace „ has „ been „ found ! " ) ; 

} 
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public void run() { 
try { 

InitValue init = new InitValue (); 

Thread [] agent = new Thread [ i n i t . numOfMutation ] ; 

for(int i=0; i<i n i t . numOfMutation ; i++) { // iterate according to the number of Mutation 
agent[i] = new Thread(new Agent ( space )) ; 

} 

for(int j =0; j <i n i t . numOfMutation ; j ++) { // iterate according to the number of Mutation 
agent [ j ] . start () ; 
agent [j ] . join () ; 

} 

} catch ( Exception e) { 
e. printStackTrace (); 

} 

} 

public static void main(String argv[]) { 

(new Thread(new RunAgentSteady State ())). s t art () ; 

} 

} 



Listing A. 12: TakeProcessor.java 

/* * 

* TakeProcessor . Java — take processor objects from the space 

* @author: Andias Wira—Alam <andias . alam@ stud . uni— due . de> 
*/ 

import net . j i n i . space . JavaSpace ; 
import net.jini .core. lease. Lease; 

public class TakeProcessor { 

public static void main(String argv[]) { 
try { 

System . out . println (" Searching „f or „ JavaSpace ...") ; 
Lookup finder = new Lookup ( JavaSpace . class ) ; 
JavaSpace space = (JavaSpace) f in der . g et S er v ice ( ) ; 
System, out. print In ( "A„ JavaSpace „has „ been „ found ! " ) ; 

ProcessorEntry ptemplate = new Proces s orEntry ( ) ; 
ProcessorEntry presult = new Proce s sorEntry ( ) ; 
InitValue init = new InitValue (); 

System . out . print In ( "Taking „processor„objects „from„ the „ space ...„") ; 
for(int i = l; i <= i n i t . numOfProcessor ; i ++) { 

presult = (ProcessorEntry) space . tak el f Ex i s t s ( ptemplate , null, Long .MAX_VALUE) ; 
if ( presult ! = null ) { 

for(int j =0; j <presult . record . size () ; j ++) { 

Sy stem . out . pri n t (" ProcID : „" + p r e s u 1 1 . proc _id+ ";„"); 
System, out. print ("start_t:„" +presult. record. get(j).get(0)+ ";„"); 
System. out. print("stop_t +presult .record . get(j ). get ( 1 )+ ";„"); 
System, out. print ("data_id:„" +presult.record.get(j).get(2)+ ";„"); 
System, out . print ("mutation : „" +presult . record . get(j ). get (3 )+ " ; ) ; 
System.out.println("step:„" +presult. record. get(j).get(4)); 

} 

} 

else { 

System . out . println (" Proce s s or „ Obj ects JMOT -FOUND! " ) ; 
break ; 

} 

} 

System . out . println ( "Done ! " ) ; 
} catch ( Exception e) { 
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e. printStackTrace (); 



Listing A. 13: TestSpace.java 

/* * 

* TestSpace . java — checking objects availability in the space 

* @author: Andias Wira—Alam <andias . alam@ stud . uni— due . de> 
*/ 

import net . j i n i . space . JavaSpace ; 
import net . jini . core . lease . Lease ; 

public class TestSpace { 

public static void main( String argv[]) { 

try { 

System . out . println ("Searching„for„JavaSpace . . . " ); 
Lookup finder = new Lookup ( JavaSpace . cl ass ) ; 
JavaSpace space = (JavaSpace) finder . getService () ; 
System .out.println( "A„ JavaSpace „ has „ been _ found ! " ) ; 

ProcessorEntry ptemplate = new Proc es s orEntry ( ) ; 
DataEntry dtemplate = new DataEntryO; 

if ( space . readlfExi st s ( ptemplate , null, Long .MAXJVALUE) != null) 
System.out.println("Object„\"processor\"„has„been„found!"); 

else 

System. out. println("Object„\"processor\"„doesn't„exist!"); 

if ( space . readlfExists ( dtemplate , null, Long .MAXJVALUE) != null) 
System, out . println ("Object„\"data\"„has„been„found !"); 

else 

System. out. println("Object„\"data\"„doesn't„exist !"); 

} catch ( Exception e) { 
e. printStackTrace (); 

} 

} 

} 



Listing A. 14: TurnEntry.java 

/* * 

* TurnEntry.java — performing "turn token" 

* @author: Andias Wira—Alam <andias . alam@ stud . uni— due . de> 
*/ 

import net . j i n i . core . entry .* ; 

public class TurnEntry implements Entry { 
public String name = null; 
public Integer value = null ; 

public TurnEntry () {} 

} 
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Appendix A Source Code 
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Appendix B 
Figures: Histogram 



This appendix contains the histograms of the overall computation time of all scenarios. 
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Figure B.l: Histogram of scenario eOO 
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Appendix B Figures: Histogram 
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Figure B.2: Histogram of scenario e02 
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Figure B.3: Histogram of scenario e!2 
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Appendix B Figures: Histogram 
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Figure B.4: Histogram of scenario e!4 
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